1. Field of the Invention
The present invention relates generally to computer implemented electronic design automation techniques to evaluate, design, and simulate embedded systems. More particularly, the present invention is directed towards the use of computer implemented techniques for the evaluation of Intellectual Property components used in embedded systems, the design of embedded systems, and the procurement of goods and services related to an embedded system.
2. Description of Background Art
There is increasing interest in embedded systems. An embedded system is a specialized computer system that is typically part of a larger system or machine. An embedded system requiring custom software is also sometimes described as a “platform.” Embedded systems are used in industrial control systems, consumer products (e.g., mobile phones and computer game consoles), and telecommunication systems.
An embedded system may include its own operating system or, in some cases, a single computer program. An embedded system commonly includes one or more microprocessors, peripheral hardware to perform input/output functions, and several software layers (e.g., device drivers, middleware, or applications). An embedded system having all of the hardware and software residing on a single chip is sometimes called a system on a chip (SOC). However, an embedded system can also be implemented as one or more printed circuit boards with the hardware components implemented as discrete integrated circuit chips.
Embedded system design includes the design of both hardware and software that must work together in the final product. Typically, the task of designing an embedded system is divided into the separate but complementary tasks of designing the hardware and the software, what is called the “hardware partition” and the “software partition.” The design of the hardware partition is facilitated by using as many commercially available hardware components as practical. In particular, the design of an embedded system is increasingly characterized by the use of pre-designed intellectual property (IP) components. An IP component (sometimes also known as an “IP block”) is commonly used to describe a component of an embedded system that is licensed to others as intellectual property. However, the term IP component is also sometimes used by engineers to describe a portion of an embedded system that is available from others. For example, a variety of companies license designs for a processor core. Thus, an embedded system designer may select a processor core suitable for an intended application and then design the remaining hardware (e.g., peripherals and buses) to implement the hardware portion. It is common for at least one portion of the hardware to be customized for a particular project. The software partition of an embedded systems project may use portions of software applications from other projects. However, typically a significant amount of code must be written for the software partition of a particular project.
FIG. 1 illustrates an exemplary embedded system design project 100 that may be divided into sequence of project phases. Exemplary times common for each phase are included on the left-hand side of the illustration. In a requirement definition phase 102, a set of requirements 104 is developed for a product idea 101. Key IP components must then be evaluated for possible use in the embedded system. Because of the nature of embedded system design, documentation alone is typically insufficient to understand how an IP component, such as a processor core, will function with a software application running user code. Consequently, the initial evaluation phase 106 may last up to several months in order to have sufficient time to identify useful IP components and to physically test the operation of software in a working test platform.
FIG. 2 is a flow chart showing in more detail some of the elements of a conventional evaluation phase 106. For the case of processor cores, this has conventionally involved identifying potential suppliers 202, contacting suppliers to request information 204, ordering and reviewing product information 206, ordering and purchasing an evaluation board 208, receiving the evaluation board, 210, installing the evaluation board 212, installing software development tools 214, customizing the evaluation board 216, running evaluation software on the test board 218, and selecting suppliers 220. Note that the supplier must also commit significant resources to provides services to prepare and send product information 222, receiving orders 224, processing orders 226, and shipping evaluation boards 228. Additionally, support must be provided to users to use the evaluation boards (not shown in FIG. 2). The resources that a vendor must devote also include the resources to design, manufacture, and keep in stock a supply of evaluation boards. In some cases, a significant time delay may be involved for a vendor to arrange for evaluation boards having custom silicon and printed circuit boards to be designed and manufactured. Moreover, each evaluation board may have a significant cost (e.g., thousands of dollars) such that a vendor will only maintain in stock a limited number of evaluation boards at any one moment of time. Consequently, in some cases embedded system designers may have to wait substantial periods of time to obtain an evaluation board.
From the standpoint of the embedded system designer, the evaluation phase 106 is a time consuming and costly process, particularly if a significant number of IP blocks from different vendors are to be evaluated. Conventionally, evaluating IP blocks from different vendors requires evaluating the operation of separate evaluation boards for each IP block. In addition to being a time consuming process, each IP block can be evaluated only in isolation, which can make it difficult to determine how several IP blocks would interact together in a single embedded system. From the perspective of the IP vendor this is a costly marketing tool that requires IP vendors to invest in creating standard test board platforms (e.g., boards including reference peripheral devices and driver applications). The cost to the IP vendor includes the cost of the evaluation boards and the support services that must be provided for potential customers to successfully evaluate each board.
After key IP components are selected, a development phase 110 begins, which commonly lasts 3-9 months. The development phase 110 commonly begins by defining the architecture 108 of the embedded system, with the system architecture including, for example, the processor(s) to be used, hardware peripherals, and user interfaces. The hardware architecture may be used to form an initial partition of the hardware and software. Conventionally, hardware development 112 proceeds faster than software development 114 because software developers need a hardware implementation to develop some types of software.
FIG. 3 is a flow chart showing in more detail some of the aspects of the development phase 110. After the system architecture is defined 108, specification documents 302 for both the hardware and the software partition are created. The hardware development begins by developing hardware components 304. The software development begins by installing an eval/reference board 350. Software engineers may use an evaluation board to develop some of the software application layers 352 but cannot start developing certain types of software (e.g., middleware and device drivers) until a hardware emulation prototype 308 is available. Other steps common in the subsequent hardware and software development are indicated on FIG. 3. Typically, the hardware must reach a high level of implementation detail before a hardware emulator having sufficient speed may be developed 306 for continued software development 354 (e.g., middleware, device drivers) to proceed. The hardware partition is commonly emulated using hardware emulation boards and hardware acceleration boxes, which feature a combination of re-programmable hardware, typically in the form of Field Programmable Gate Arrays (FPGA), and plugable modules/boards containing the processor(s) that will emulate the hardware partition.
Hardware emulators are commonly a factor of 100 or more slower than the final physical system but provide sufficient speed to debug software. Unfortunately it may take up to two-thirds of the development cycle before the hardware implementation reaches a high level of implementation detail and a physical hardware emulator 308 is configured. This means that feedback 356 to refine hardware components 310 comes later than desired. Moreover, early software integration 358 must wait until hardware components have been fabricated 312 and a PCB prototype designed 314 and fabricated 316. After the results of the early PCB prototype 360, hardware development proceeds 318, 320, 322, and 324 towards a final PCB prototype upon which final software integration and testing 360 may be performed. Note that FIG. 3 assumes that hardware emulator is used. However, a conventional hardware emulator is comparatively expensive. In some embedded system projects a hardware emulator (e.g., a FPGA hardware emulator) may not be cost effective such that much of the software development and integration must wait until a physical prototype is available.
Referring again to FIG. 1, note that the procurement of many goods or services required for the manufacture of an embedded system often must wait until a tested prototype 120 is available after a quality assurance and testing phase 118, which uses a prototype 116. Procurement significantly earlier than the tested prototype stage 120 is typically impractical because there is an insufficient quantity and quality of documentation prior to the tested prototype stage that would permit procurement needs to be adequately communicated with vendors. The procurement phase 122 may include purchasing components, PCB boards, IP licenses, and arranging for semiconductor fabrication of custom silicon chips required for a manufacturing and assembly phase 126 to produce a final product 128 on a pre-product definition 124.
Embedded systems designers are under increasing pressure to reduce the time to market and to increase the software functionality of embedded systems, which in turn tends to increase the complexity of embedded system software. Embedded system design projects would be facilitated if there were a computer aided design tool that permitted the efficient selection of a processor core or other IP components, facilitated the co-design of both the hardware and software partition, and facilitated the procurement of IP components and other necessary services. However, conventional automated design tools have serious shortcomings that limit their usefulness in the design cycle, particularly for embedded systems executing complex software applications. Moreover, conventional automated design tools also have shortcomings in speed, user-friendliness, and security that have hindered the development of web-based design tools.
One drawback of conventional electronic design approaches for embedded systems is that they are hardware-centric and typically have an execution speed that is too slow for the simulation to serve as a hardware emulator for the purposes of debugging software. For example, one conventional electronic design method is to use a hardware definition language (HDL) to model the hardware partition at the hardware implementation level. However, modeling the hardware implementation in HDL requires that the hardware be extensively developed (e.g., fully detailed) before the software, which can require a significant length of time in the development cycle.
In addition to its other problems, a HDL simulation (e.g., one using a cycle-accurate processor model and a detailed implementation model of hardware) has such a high level of implementation detail that a software application executed on HDL simulation of the hardware partition would be too slow for meaningful software debugging during a typical development phase. As one example, a software application running on virtual hardware needs a comparatively high execution speed to detect deadlocked situations between multiple on-chip processors. As another example, a software application running on virtual hardware needs a comparatively high execution speed to perform a booting test of a full-fledge operating system (OS) on the hardware being designed. However, HDL models typically execute at too slow a speed to permit a software designer to evaluate the system aspects in which a software designer is interested.
A further drawback of HDL models is that it is often impractical to share them with third parties that are not legally bound to maintain the confidentiality of the model. An HDL description of an embedded system includes implementation details required to fabricate an end product. HDL models have such a high level of implementation detail that companies are reluctant to share HDL models with other companies for fear of losing valuable proprietary trade secrets. As one consequence, IP vendors typically do not provide HDL models of their products for evaluation. Another consequence is that embedded system designers and IP vendors typically do not make HDL models of IP components and sub-systems available on the Internet.
The problems associated with conventional embedded system design projects can be anticipated to become worse as improvements in the processing power of embedded systems permits embedded systems having more complex software applications. This can be expected to increase the need to rapidly and effectively evaluate IP blocks during the evaluation phase, to accelerate the pace of software development during the development cycle, and to improve the procurement of goods and services related to the embedded system project, including the licensing of IP blocks. However, conventional automated design tools do not provide the right level of abstraction, quick model creation, ease of use, execution speed, and understandability to permit substantial improvements in the evaluation, development, and procurement phases of an embedded system design project.
What is desired is a computer-aided system and method for improving the evaluation, development, and procurement phases of an embedded system development project.